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Abstract 
This document specifies a general channel mechanism for sending 
messages, such as Bidirectional Forwarding Detection (BFD) messages, 
between Routing Bridges (RBridges) and between RBridges and end 
stations in an RBridge campus through extensions to the Transparent 
Interconnection of Lots of Links (TRILL) protocol. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7178. 
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Copyright Notice 


Copyright (c) 2014 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. 


Introduction 


RBridge campuses provide transparent least-cost forwarding using the 
Transparent Interconnection of Lots of Links (TRILL) protocol that 
builds on Intermediate System to Intermediate System (IS-IS) routing 
[IS-IS] [RFC1195] [RFC7176]. Devices that implement TRILL are called 
Routing Bridges (RBridges) or TRILL Switches. However, the TRILL 
base protocol standard [RFC6325] provides only for TRILL Data 
messages and TRILL IS-IS messages. 


This document specifies a general channel mechanism for the 
transmission of other messages within an RBridge campus, such as BFD 
[RFC5880] messages, (1) between RBridges and end stations that are 
directly connected on the same link and (2) between RBridges. This 
mechanism supports a requirement to be able to operate with minimal 
configuration. 


1. RBridge Channel Requirements 


It is anticipated that various protocols operating at the TRILL layer 
will be desired in RBridge campuses. For example, there is a need 
for rapid-response continuity checking with a protocol such as BFD 
[RFC5880] [RFC5882] and for a variety of optional reporting. 


To avoid the requirement to design and specify a way to carry each 
such protocol, this document specifies a general channel for sending 
messages between RBridges in a campus at the TRILL level by extending 
the TRILL protocol. To accommodate a wide variety of protocols, this 
RBridge Channel facility accommodates all the regular modes of TRILL 
Data transmission including single- and multiple-hop unicast as well 
as VLAN-scoped multi-destination distribution. 


To minimize any unnecessary burden on transit RBridges and to provide 
a more realistic test of network continuity and the like, RBridge 
Channel messages are designed to look like TRILL Data frames and, in 
the case of multi-hop messages, can normally be handled by transit 
RBridges as if they were TRILL Data frames; however, to enable 
processing at transit RBridges when required by particular messages, 
they may optionally use the RBridge Channel Alert TRILL extended 
header flags [RFC7179] that causes a transit RBridge implementing the 
flag to more closely examine a flagged frame. 


This document also specifies a format for sending RBridge Channel 
messages between RBridges and end stations that are directly 
connected over a link, in either direction, when provided for by the 
protocol involved. For the most part, this format is the same as the 
format that is encapsulated by TRILL Data for inter-RBridge Channel 
messages. 
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Each particular protocol using the RBridge Channel facility will 
likely use only a subset of the facilities specified herein. 


1.2. Relation to the MPLS Generic Associated Channel 


The RBridge Channel is similar to the MPLS Generic Associated Channel 
Specified in [RFC5586]. Instead of using a special MPLS label to 
indicate a special channel message, an RBridge Channel message is 
indicated by a special multicast Inner.MacDA and inner Ethertype (see 
Section 2.1). 


1.3. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 


document are to be interpreted as described in [RFC2119]. 


The terminology and acronyms of [RFC6325] are used in this document 
with the additions listed below. 


BFD - Bidirectional Forwarding Detection 

CHV - Channel Header Version 

MH - Multi-Hop 

NA - Native 

SL - Silent 

2.  Inter-RBridge Channel Messages 

Channel messages between RBridges are transmitted as TRILL Data 
frames. (For information on channel messages that can be transmitted 
between RBridges and end stations that are directly connected by a 
link, see Section 4.)  Inter-RBridge Channel messages are identified 
as such by their Inner.MacDA, which is the All-Egress-RBridges 
multicast address, together with their inner Ethertype, which is the 


RBridge-Channel Ethertype. This Ethertype is part of and starts the 
RBridge Channel Header. 
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The diagram below shows the overall structure of an RBridge Channel 
Message frame on a link between two RBridges: 


Frame Structure Section of This Document 
4-—------------------------------ * 
| Link Header | Section 2.3 if Ethernet link 
Fan A T + 
| TRILL Header | Section 2.2 
-—------------------------------ * 
| Inner Ethernet Header | Section 2.1.2 
fae E a aaa + 
| RBridge Channel Header | Section 2.1.1 
tas A A SA + 
| Protocol-Specific Payload | See specific channel protocol 
rI i AA A + 
| Link Trailer (FCS if Ethernet) | 
A E E E + 


Figure 1: RBridge Channel Frame Structure 


Optionally, some channel messages may require examination of the 
frame by transit RBridges that support the RBridge Channel feature, 
to determine if they need to take any action. To indicate this, such 
messages use an RBridge Channel Alert extended TRILL Header flag as 
further described in Section 3 below. 


Sections 2.1 and 2.2 describe the inner frame and the TRILL Header 
for frames sent in an RBridge Channel. As always, the outer Link 
Header and Link Trailer are whatever is needed to get a TRILL Data 
frame to the next-hop RBridge, depending on the technology of the 
link, and can change with each hop for multi-hop messages. Section 
2.3 describes the outer Link Header for Ethernet links, and Section 
2.4 discusses some special considerations for the first hop 
transmission of RBridge Channel messages. 


Section 3 describes some details of RBridge Channel message 
processing. Section 4 provides the specifications for native RBridge 
Channel frames between RBridges and end stations that are directly 
connected over a link. Section 5 describes how support for RBridge 
Channel protocols is indicated. And Sections 6, 7, and 8 give 
congestion, allocation (IANA and IEEE), and security considerations 
respectively. 
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2.1. RBridge Channel Message Inner Frame 


The encapsulated inner frame within an RBridge Channel message frame 
is as shown below. 


0 I 2 3 
O. L2 34568 8:90 «b 22° 3" ANS 6 3 78:9: QE 2-8 44.75 765 T goa 0 L 
Inner Ethernet Header: 
T-—R——R——.—L—.— -— 4-4 4-4 B6 
| Special Inner.MacDA = All-Egress-RBridges 
t—+-+-4+-+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-4t-4+-4-4t-4+-4-4-4+-4t-4-4+-4-4-4 
| Special Inner.MacDA cont. | Inner.MacSA 
+—+-+-4+-+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4t-4+-4+-4t-4-4-4+-4+-4-4-4+-4-4-4-4-4-4 
| Inner.MacSA cont. | 
t—+-+-4+-+-4-4-4+-4+-4+-4-4+-4+-4-4-4+-4+-4-4-4t-4+-4-4+-4+-4-4-4+-4+-4-4+-4-4-4 
| VLAN Tag Ethertype Priority, DEI, VLAN ID 
t—+—+-4+-+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-4t-4+-4-4+-4+-4-4-4+-4t-4-4+-4-4+-4 
RBridge Channel Header: 
t-+—-+-4+-+-4+-4-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-t-4+-4-4t-4+-4-4-4+-4t-4-4-4t-4+-4 


| RBridge-Channel Ethertype | CHV Channel Protocol 
Hott ttt tat tat titi titi tai ————— ti to tititat 
| Flags | ERR | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Information specific to the RBridge Channel Protocol: 
t—+-+-4+-+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4+-4t-4+-4-4t-4+-4-4-4+-4-4+-4+-4-4-4 


+ Channel-Protocol-Specific Data 


Figure 2: RBridge Channel Inner Frame Header Fields 


The Channel-Protocol-Specific Data contains the information related 
to the specific channel protocol used in the channel message. 
Details of that data are outside the scope of this document, except 
in the case of the RBridge Channel Error protocol specified in 
Section 3.2. 


2.1.1. RBridge Channel Header 
As shown in Figure 2, the RBridge Channel Header starts with the 
RBridge-Channel Ethertype (see Section 7.2). Following that is a 


four-byte quantity with four sub-fields as follows: 


CHV: A 4-bit field that gives the RBridge Channel Header Version. 
This document specifies version zero. 
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Channel Protocol: A 12-bit unsigned integer that specifies the 
particular RBridge Channel protocol to which the message 
applies. 


Flags: Provides 12 bits of flags as described below. 


ERR: A 4-bit unsigned integer used in connection with error 
reporting at the RBridge Channel level as described in Section 
3. 


The flag bits are numbered from 0 to 11 as shown below. 


|i» dbocES 30.04 25. 3673 UR 79-419 7051 
4-—--—4--—4--4--4--4--4--4--4--4--4-- 
|SL|MH|NA| Reserved | 
+--+--+--+--+--+--+--+--+--+--+--+-—+ 


Figure 3: Channel Header Flag Bits 


Bit 0: The SL or Silent bit, the high-order bit in network order. 
If it is a one, it suppresses RBridge Channel Error messages 
(see Section 3). 


Bit 1: The MH or Multi-Hop bit. It is used to inform the 
destination RBridge protocol that the message may be multi-hop 
(MH-1) or was intended to be one-hop only (MH=0). 


Bit 2: The NA or Native bit. It is used as described in Section 
4. 


Reserved: Bits reserved for future specification that MUST be sent 
as zero and ignored on receipt. 


The RBridge Channel Protocol field specifies the protocol that the 


channel message relates to. The initial defined value is listed 
below. 
Protocol Name - Section of This Document 
0x001 RBridge Channel Error - Section 3 


IANA Considerations for RBridge Channel protocol numbers are provided 
in Section 7. These include provisions for Private Use protocol 
numbers. Because different uses of Private Use RBridge Channel 
protocol numbers may conflict, such use MUST be within a private 
network. It is the responsibility of the private network manager to 
avoid conflicting use of these code points and unacceptable burdens 
within the private network from their use. 
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241.2. Inner Ethernet Header 


The special Inner.MacDA is the All-Egress-RBridges multicast Media 
Access Control (MAC) address to signal that the frame is intended for 
the egress (decapsulating) RBridge itself (or the egress RBridges 
themselves if the frame is multi-destination). (This address is 
called the All-ESADI-RBridges address in [RFC6325].) The RBridge- 
Channel Ethertype indicates that the frame is an RBridge Channel 
message. The only other Ethertype currently specified for use with 
the All-Egress-RBridges Inner.MacDA is L2-IS-IS to indicate an ESADI 
frame [RFC6325]. In the future, additional Ethertypes may be 
Specified for use with the All-Egress-RBridges multicast address. 


The RBridge originating the channel message selects the Inner.MacSA. 
The Inner.MacSA MUST be set by the originating RBridge to a MAC 
address unique within the campus owned by the originating RBridge. 
This MAC address can be considered, in effect, the MAC address of a 
virtual internal end station that handles the RBridge Channel frames 
originated by or destined for that RBridge. It MAY be the same as 
the Inner.MacSA used by the RBridge when it originates ESADI frames 
[RFC6325]. 


2.1.3.  Inner.VLAN Tag 


As with all frames formatted to be processed as a TRILL Data frame, 
an Inner.VLAN tag is present. Use of a VLAN tag Ethertype other than 
0x8100 or stacked tags is beyond the scope of this document but is an 
obvious extension. 


Multi-destination RBridge Channel messages are, like all multi- 
destination TRILL Data messages, VLAN scoped so the Inner.VLAN ID 
MUST be set to the VLAN of interest. To the extent that distribution 
tree pruning is in effect in the campus, such channel messages may 
only reach RBridges advertising that they have connectivity to that 
VLAN. 


For channel messages sent as known unicast TRILL Data frames, the 
default value for the Inner.VLAN ID is VLAN 1, but particular RBridge 
Channel protocols MAY specify other values. 


The Inner.VLAN also specifies a three-bit frame priority for which 
the following recommendations apply: 


1. For one-hop channel messages critical to network connectivity, 


such as one-hop BFD for rapid link-failure detection in support 
of TRILL IS-IS, the RECOMMENDED priority is 7. 
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2. For single and multi-hop unicast channel messages important to 
network operation but not critical for connectivity, the 
RECOMMENDED priority is 6. 


3. For other unicast channel messages and all multi-destination 
channel messages, it is RECOMMENDED that the default priority 
zero be used. In any case, priorities higher than 5 SHOULD NOT 
be used for such frames. 


There is one additional bit in a VLAN tag value between the 12-bit 
VLAN ID and 3-bit priority, the Drop Eligibility Indicator (DEI) 
[RFC7180]. It is RECOMMENDED that this bit be zero for the first two 
categories of channel messages listed immediately above. The setting 
of this bit for channel messages in the third category may be 
dependent on the channel protocol and no general recommendation is 
made for that case. 


2.2. TRILL Header for RBridge Channel Messages 


After the outer Link Header (that, for an Ethernet link, ends with 
the TRILL Ethertype) and before the encapsulated frame, the channel 
message's TRILL Header initially appears as follows: 


0 1 2 3 
0: 12.3 4:56 7.8 9 0 12.3 4.5.67 8 9 O 12 3.45 6 7-8.9 0: 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


|v=0| R |M| Op-Len | Hop Count | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Egress Nickname | Ingress Nickname 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 4: RBridge Channel TRILL Header Fields 


The TRILL Header version (V) MUST be zero; the R bits are reserved; 
the M bit is set appropriately as the channel message is to be 
forwarded as known destination unicast (M-0) or multi-destination 
(M-1), regardless of the fact that the Inner.MacDA is always the All- 
Egress-RBridges multicast address; and Op-Len is set appropriately 
for the length of the TRILL Header extensions area, if any, all as 
Specified in [RFC6325]. 


When an RBridge Channel message is originated, the Hop Count field 
defaults to the maximum value, O0Ox3F, but particular RBridge Channel 
protocols MAY specify other values. For messages sent a known number 
of hops, such as one-hop messages or a two-hop self-addressed message 
intended to loop back through an immediate neighbor RBridge, setting 
the Hop Count field in the TRILL Header to the maximum value and 
checking its value on receipt provides an additional validity check 
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as discussed in [RFC5082], where this type of field is referred to as 
"TTL" or "Hop Limit". 


The RBridge originating a channel message places a nickname that it 
holds in the Ingress Nickname field. 


There are several cases for the Egress Nickname field. If the 
channel message is multi-destination, then the Egress Nickname 
designates the distribution tree to use. If the channel message is a 
multi-hop unicast message, then the Egress Nickname is a nickname of 
the target RBridge; this includes the special case of a message 
intended to loop back from an immediate neighbor where the originator 
places one of its own nicknames in both the Ingress Nickname and 
Egress Nickname fields. If the channel message is a one-hop unicast 
message, there are two possibilities for the Egress Nickname. 


o The Egress Nickname can be set to a nickname of the target 
neighbor RBridge. 


o The special nickname Any-RBridge may be used. RBridges supporting 
the RBridge Channel facility MUST recognize the Any-RBridge 
Special nickname and accept TRILL Data frames having that value in 
the Egress Nickname field as being sent to them as the egress. 
Thus, for such RBridges, using this egress nickname guarantees 
processing by an immediate neighbor regardless of the state of 
nicknames. 


2.3. Ethernet Link Header and Trailer 


An RBridge Channel frame has the usual Link Header and Link Trailer 
for a TRILL Data frame depending on the type of link on which it is 
sent. 


For an Ethernet link [RFC6325], the Outer.MacSA is the MAC address of 
the port from which the frame is sent. The Outer.MacDA is the MAC 
address of the next-hop RBridge port for unicast RBridge Channel 
messages or the All-RBridges multicast address for multi-destination 
RBridge Channel messages. The Outer.VLAN tag specifies the 
designated VLAN for that hop, and the priority should be the same as 
in the Inner.VLAN tag; however, the output port may have been 
configured to strip VLAN tags, in which case no Outer.VLAN tag 
appears on the wire. And the Link Trailer is the Ethernet FCS. 


2.4. Special Transmission and Rate Considerations 
If a multi-hop RBridge Channel message is received by an RBridge, the 


criteria and method of forwarding it are the same as for any TRILL 
Data frame. If it is so forwarded, it will be on a link that was 
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included in the routing topology because it was in the Report state 
as specified in [RFC7177]. 


However, special considerations apply to single-hop messages because, 
for some RBridge Channel protocols, it may be desirable to send 
RBridge Channel messages over a link that is not yet fully up. In 
particular, it is permissible, if specified by the particular channel 
protocol, for the source RBridge that has created an RBridge Channel 
message to attempt to transmit it to a next-hop RBridge when the link 
is in the Detect or 2-Way state, as specified in [RFC7177], as well 
as when it is in the Report state. Such messages can also be sent on 
point-to-point links that are not in the Up state. 


RBridge Channel messages represent a burden on the RBridges, and 
links in a campus and should be rate limited, especially if they are 
sent as high priority, multi-destination, or multi-hop frames or have 
an RBridge Channel Alert extended header flag set. See Section 6, 
"Congestion Considerations". 


3. Processing RBridge Channel TRILL Data Messages 


RBridge Channel TRILL Data messages are designed to look like and, to 
the extent practical, be forwarded as regular TRILL Data frames. On 
receiving a channel message, an RBridge performs the usual initial 
tests on the frame and makes the same forwarding and/or decapsulation 
decisions as for a regular TRILL Data frame [RFC6325] with the 
following exceptions for RBridges implementing the RBridge Channel 
facility: 


1. An RBridge implementing the RBridge Channel facility MUST 
recognize the Any-RBridge egress nickname in TRILL Data frames, 
decapsulating such frames if they meet other checks. (Such a 
frame cannot be a valid multi-destination frame because the Any- 
RBridge nickname is not a valid distribution tree root.) 


2. If an RBridge Channel Alert extended header flag is set, then the 
RBridge MUST process the RBridge Channel message as described 
below even if it is not egressing the frame. If it is egressing 
the frame, then no additional processing beyond egress processing 
is needed even if an RBridge Channel Alert flag is set. 


3. On decapsulation, the special Inner.MacDA value of All-Egress- 
RBridges MUST be recognized to trigger checking the 
Inner.Ethertype and processing as an RBridge Channel message if 
that Ethertype is RBridge-Channel. 
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RBridge Channel messages SHOULD only be sent to RBridges that 
advertise support for the channel protocol involved as described in 
Section 5. 


All RBridges supporting the RBridge Channel facility MUST recognize 
the RBridge-Channel inner Ethertype. 


3.1. Processing the RBridge Channel Header 


Knowing that it has an RBridge Channel message, the egress RBridge, 
and any transit RBridge if an RBridge Channel Alert bit is set in the 
TRILL Header, looks at the CHV (RBridge Channel Header Version) and 
Channel Protocol fields. 


If any of the following conditions occur at an egress RBridge, the 
frame is not processed, an error may be generated as specified in 
Section 3.2, and the frame is discarded. The behavior is the same if 
the frame is being processed at a transit RBridge because the RBridge 
Critical Channel Alert flag is set [RFC7179]. However, if these 
conditions are detected at a transit RBridge examining the message 
because the RBridge Non-critical Channel Alert flag is set [RFC7179] 
but the RBridge Critical Channel Alert flag is not set, no error is 
generated, and the frame is still forwarded normally. 


Error Conditions: 


1. The Ethertype is not RBridge-Channel and not any other Ethertype 
known to the RBridge as usable with the All-Egress-RBridges 
Inner.MacDA, or the frame is so short that the Ethertype is 
truncated. 


2. The CHV field is non-zero, or the frame is so short that the 
version zero Channel Header is truncated. 


3. The Channel Protocol field is a reserved value or a value unknown 
to the processing RBridge. 


4. The ERR field is non-zero, and Channel Protocol is a value other 
than 0x001. 


5. The RBridge Channel Header NA flag is set to one, indicating that 
the frame should have been received as a native frame rather than 
a TRILL Data frame. 


If the CHV field and NA flag are zero and the processing RBridge 
recognizes the Channel Protocol value, it processes the message in 
accordance with that channel protocol. The processing model is as if 
the received frame starting with and including the TRILL Header is 
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eos 


delivered to the Channel protocol along with a flag indicating 
whether this is (a) transit RBridge processing due to an RBridge 
Channel Alert flag being set or (b) egress processing. 


Errors within a recognized Channel Protocol are handled by that 
channel protocol itself and do not produce RBridge Channel Error 
frames. 


RBridge Channel Errors 


A variety of problems at the RBridge Channel level cause the return 
of an RBridge Channel Error frame unless one of the following apply: 
(a) the "SL" (Silent) flag is a one in the channel message for which 
the problem was detected, (b) the processing is due to the RBridge 
Non-critical Channel Alert flag being set, (c) the frame in error 
appears, itself, to be an RBridge Channel Error frame (has a non-zero 
ERR field or a Channel Protocol of 0x001), or (d) the error is 
suppressed due to rate limiting. 


An RBridge Channel Error frame is a multi-hop unicast RBridge Channel 
message with the Ingress Nickname set to a nickname of the RBridge 
detecting the error and the Egress Nickname set to the value of the 
Ingress Nickname in the channel message for which the error was 
detected. No per-hop transit processing is specified for such error 
frames, so the RBridge Channel Alert extended header flags SHOULD, if 
an extension is present, be set to zero. The SL and MH flags SHOULD 
be set to one; the NA flag MUST be zero; and the ERR field MUST be 
non-zero as described below. For the protocol-specific data area, an 
RBridge Channel Message Error frame has at least the first 256 bytes 
(or less if less are available) of the erroneous decapsulated channel 
message starting with the TRILL Header. (Note: The TRILL Header does 
not include the TRILL Ethertype that is part of the Link Header on 
Ethernet links.) 


The following values for ERR are specified: 
ERR RBridge Channel Error Code Meaning 


0 No error 

1 Frame too short (truncated Ethertype or Channel Header) 
2 Unrecognized Ethertype 

3 Unimplemented value of CHV 

4 Wrong value of NA flag 


5 Channel Protocol is reserved or unimplemented 
6-14 Unassigned (see Section 7) 
15 Reserved (see Note) 
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Note: Intended to be allocated by Standards Action for an error 
code expansion feature when it appears likely that all 
other available error codes are being allocated. 


All RBridges implementing the RBridge Channel feature MUST recognize 
the RBridge Channel Error protocol value (0x001). They MUST NOT 
generate an RBridge Channel Error message in response to an RBridge 
Channel Error message, that is, a channel message with a protocol 
value of 0x001 or with a non-zero ERR field. 


4. Native RBridge Channel Frames 


Other sections of this document specify non-native RBridge Channel 
messages and their processing, that is, RBridge Channel messages 


formatted as TRILL Data frames and sent between RBridges. This 
section specifies the differences for native RBridge Channel 
messages. 


If provided for by the channel protocol involved, native RBridge 
Channel messages may be sent between end stations and RBridges that 
are directly connected over a link, in either direction. On an 
Ethernet link, such native frames have the RBridge-Channel Ethertype 
and are like the encapsulated frame inside an RBridge Channel message 
except as follows: 


1. TRILL does not require the presence of a VLAN tag on such native 
RBridge Channel frames. However, port configuration, link 
characteristics, or the channel protocol involved may require 
such tagging. 


2. If the frame is unicast, the destination MAC address is the 
unicast MAC address of the RBridge or end-station port that is 
its intended destination. If the frame is multicast by an end 
station to all the RBridges on a link that support an RBridge 
Channel protocol using this transport, the destination MAC 
address is the All-Edge-RBridges multicast address (see Section 
7). A native RBridge Channel frame received at an ingress 

RBridge is discarded if its destination MAC address is neither 

the unicast address of the port nor the multicast address All- 

Edge-RBridges. If the frame is multicast by an RBridge to all 

the devices that TRILL considers to be end stations on a link and 

that support an RBridge Channel protocol using this transport, 
the destination MAC address is the TRILL-End-Stations multicast 
address (see Section 7). A native RBridge Channel frame received 
at an end station is discarded if its destination MAC address is 
neither the unicast address of the port nor the multicast address 

TRILL-End-Stations. 


Eastlake, et al. Standards Track [Page 14] 


RFC 7178 TRILL: RBridge Channel Support May 2014 


3. The RBridge-Channel outer Ethertype must be present. In the 
future, there may be other protocols using the All-Edge-RBridges 
and/or TRILL-End-Stations multicast addresses on native frames 
distinguished by different Ethertypes. 


4. The NA or Native bit in the RBridge Channel Header flags MUST be 
a one. 


5. There might be additional tags present between the Outer.MacDA, 
Outer.MacSA pair, and the RBridge-Channel Ethertype. 


The RBridge Channel protocol number space for native RBridge Channel 
messages and TRILL Data formatted RBridge Channel messages is the 
same. If provided for by the channel protocol involved, the receipt 
of a native RBridge Channel frame MAY lead to the generation and 
transmission of one or more Inter-RBridge Channel frames. The 
decapsulation and processing of a TRILL Data RBridge Channel frame 
MAY, if provided for by the channel protocol involved, result in the 
sending of one or more native RBridge Channel frames to one or more 
end stations. Thus, there could be an RBridge Channel protocol that 
involved an RBridge Channel message sent (1) from an origin RBridge 
where the message is created, (2) through one or more transit 
RBridges, and (3) from a final RBridge as a native RBridge Channel 
message to an end station (or the reverse of such a three-part path); 
however, to do this, the RBridge Channel protocol involved must be 
implemented at the RBridge where the channel message is changed 
between a native frame and a TRILL Data format frame, and that 
RBridge must change the channel message itself, at a minimum 
complementing the NA flag in the Channel Header and making 
appropriate MAC address changes. 


An erroneous native channel message results in a native RBridge 
Channel Error message under the same conditions for which a TRILL 
Data RBridge Channel message would result in a TRILL Data RBridge 
Channel Error message. However, in a native RBridge Channel Error 
message, the NA flag MUST be one. Also, since there is no TRILL 
Header in native RBridge Channel protocol frames, the beginning part 
of the frame in which the error was detected that is included in 
native RBridge Channel Error frames starts with the RBridge Channel 
Header (including the RBridge-Channel Ethertype). The destination 
MAC address of such error messages is set to the source MAC address 
of the native RBridge Channel message that was in error. 


There is no mechanism to stop end stations from directly exchanging 
native RBridge Channel messages, but such usage is beyond the scope 
of this document. 
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Indicating Support for RBridge Channel Protocols 


Support for RBridge Channel protocols is indicated by the presence of 
one or more TLVs and/or sub-TLVs in an RBridge's Link State PDU (LSP) 
as documented in [RFC7176]. 


RBridge Channel protocols 0 and OxFFF are reserved, and protocol 1, 
the RBridge Channel Error protocol, MUST be implemented as part of 
the RBridge Channel feature. Thus, if an RBridge supports the 
RBridge Channel feature, it should be advertising support for 
protocol 1 and not advertising support for protocols 0 or OxFFF in 
its LSP. However, indication of support or non-support for RBridge 
Channel protocol 1 is ignored on receipt, and support for it is 
always assumed if support for any RBridge Channel is indicated in the 
RBridge's LSP. 


Congestion Considerations 


The bandwidth resources used by RBridge Channel protocols are 
recommended to be small compared to the total bandwidth of the links 
they traverse. When doing network planning, the bandwidth 
requirements for TRILL Data, TRILL IS-IS, TRILL ESADI, RBridge 
Channel protocol traffic, and any other link-local traffic need to be 
taken into account. 


Specifications for particular RBridge Channel protocols MUST consider 
congestion and bandwidth usage implications and provide guidance on 
bandwidth or packet-frequency management.  RBridge Channel protocols 
can have built-in bandwidth management in their protocols. Outgoing 
channel messages SHOULD be rate-limited, by configuring the 
underlying protocols or otherwise, to prevent aggressive connectivity 
verification or other applications consuming excessive bandwidth, 
causing congestion, or becoming denial-of-service attacks. 


If these conditions cannot be followed, an adaptive loss-based scheme 
SHOULD be applied to congestion-control outgoing RBridge Channel 
traffic, so that it competes fairly, taking into account packet 
priorities and drop eligibility as indicated in the Inner.VLAN, with 
TCP or similar traffic within an order of magnitude. One method of 
determining an acceptable bandwidth for RBridge Channel traffic is 
described in [RFC5348]; other methods exist. For example, bandwidth 
or packet-frequency management can include any of the following: a 
negotiation of transmission interval/rate such as that provided in 
BFD [RFC5880], a throttled transmission rate on "congestion detected" 
Situations, a gradual ramp-up after shutdown due to congestion and 
until basic connectivity is verified, and other mechanisms. 
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Connectivity-checking applications such as BFD [RFC5880] SHOULD be 
rate-limited to below 5$ of the bitrate of the associated link or 
links. For this purpose, the mean or sustained bitrate of the link 
or links is used. 


Incoming RBridge Channel messages MAY be rate-limited as a protection 
against denial-of-service attacks. This throttling of incoming 
messages SHOULD honor packet priorities and drop eligibility 
indications as indicated in the Inner.VLAN, preferentially discarding 
drop-eligible and lower-priority packets. 


7. Allocation Considerations 
The following subsections give IANA and IEEE allocation 
considerations. In this document, the allocation procedure 
Specifications are as defined in [RFC5226]. 

7.1. IANA Considerations 
IANA has allocated a previously unassigned TRILL Nickname as follows: 

Any-RBridge OxFFCO 

IANA has added "All-Egress-RBridges" to the TRILL Parameter Registry 
as an alternative name for the "All-ESADI-RBridges" multicast 


address. 


IANA has allocated two previously unassigned TRILL multicast 
addresses as follows: 


TRILL-End-Stations 01-80-C2-00-00-45 
All-Edge-RBridges 01-80-C2-00-00-46 


IANA has created an additional sub-registry in the TRILL Parameter 
Registry for RBridge Channel Protocols, with initial contents as 


follows: 
Protocol Description Reference 
0x000 Reserved; not to be allocated (This document) 
0x001 RBridge Channel Error (This document) 


0x002-0x0FF Unassigned (1) 

0x100-0xFF7 Unassigned (2) 

OxFF8-OxFFE Reserved for Private Use 

OxFFF Reserved; not to be allocated (This document) 
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(1) RBridge Channel protocol code points from 0x002 to OxOFF require 
a Standards Action, as modified by [RFC7120], for allocation. 


(2) RBridge Channel protocol code points from 0x100 to OxFF7 are RFC 
Required to allocate a single value or IESG Approval to allocate 
multiple values. 


IANA has created an additional sub-registry in the TRILL Parameter 
Registry for RBridge Channel Header Flags with initial contents as 
follows: 


Flag Bit Mnemonic Allocation 


0 SL Silent 

1 MH Multi-hop 
2 NA Native 
3211 - Unassigned 


Allocation of an RBridge Channel Header Flag is based on IETF Review. 


IANA has created an additional sub-registry in the TRILL Parameter 
Registry for RBridge Channel Error Codes with initial contents as 
listed in Section 3.2 above and with available values allocated by 
Standards Action as modified by [RFC7120]. 


7.2. IEEE Registration Authority Considerations 


The IEEE Registration Authority has assigned the Ethertype 0x8946 for 
TRILL RBridge Channel. 


8. Security Considerations 


No general integrity, authentication, or encryption mechanisms are 
provided herein for RBridge Channel messages. If these services are 
required for a particular RBridge Channel protocol, they MUST be 
supplied by that channel protocol. See, for example, the BFD 
Authentication mechanism [RFC5880]. 


See [RFC6325] for general TRILL security considerations. As stated 
therein, no protection is provided by TRILL against forging of the 
Ingress Nickname in a TRILL Data formatted channel message or the 
Outer.MacSA in a native RBridge Channel frame on an Ethernet link. 
This may result in misdirected return responses or error messages. 
However, link-level security protocols may be used to authenticate 
the origin station on a link and protect against attacks on links. 
See also Section 6 concerning congestion. 
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9: 


9. 


If indications of RBridge Channel Protocol support are improperly 
absent from an RBridge's LSP, it could deny all RBridge Channel 
Services, for example, some BFD services, for the RBridge in 
question. If a particular RBridge Channel protocol is incorrectly 
not advertised as supported, it could deny the service of that 
channel protocol to the RBridge in question. 


Incorrect indication of RBridge Channel Protocol support or incorrect 
assertion of support for a channel protocol could encourage RBridge 
Channel messages to be sent to an RBridge that does not support the 
channel feature or the particular channel protocol used. The inner 
frame of such messages could be decapsulated and that inner frame 
could be sent out all ports that are Appointed Forwarders for the 
frame's Inner.VLAN. However, this is unlikely to cause much harm; in 
particular, there are two possibilities as follows: (a) if end 
stations do not recognize the RBridge-Channel Ethertype of the frame, 
they will drop it, and (b) if end stations do recognize the RBridge- 
Channel Ethertype and the channel protocol indicated in the frame, 
they should refuse to process the frame due to an incorrect value of 
the RBridge Channel Header NA flag. 
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